fix: Default to day-first format for invalid/unknown locales#1168
Merged
Conversation
## Problem Previously, when an invalid or unknown locale was provided, the code would catch the exception and default to month-first (American) format by returning False. This is incorrect because: 1. Most of the world uses day-first format (DD/MM/YYYY) 2. Only en_US and a few other locales use month-first (MM/DD/YYYY) 3. Defaulting to the less common format causes more parsing errors Example bug: - User provides locale "xyz_ABC" (typo or unknown locale) - Date "01/02/2023" gets parsed as January 2nd (month-first) - Should be parsed as February 1st (day-first, more common globally) ## Solution Changed the exception handler in `_should_use_day_first()` to return True (day-first) instead of False (month-first) for invalid locales. The logic now: - locale_str is None → False (backward compat, American default) - Valid locale → check Babel CLDR data - Invalid locale → True (day-first is global default) ## Testing - Updated test: `test_invalid_locale_returns_true()` - Added test: `test_invalid_locale_defaults_to_day_first()` - Confirms "01/02/2023" with invalid locale → February 1st (day-first) - All 19 timestamp parser tests pass Co-Authored-By: Claude Opus 4.1 <noreply@anthropic.com>
ajcariaga16
approved these changes
Apr 8, 2026
nathan-stender
added a commit
that referenced
this pull request
Apr 8, 2026
### Added - Add locale-aware timestamp parsing using Babel CLDR data (#1167) - Add global locale support for number parsing (#1165) - Reduce Cytiva Biacore T200 Control memory usage with cycle streaming (#1164) - Cytiva T200 - Implement streaming decoder to reduce memory usage by 55% (#1163) ### Fixed - Default to day-first format for invalid/unknown locales (#1168) - Use immutable copy pattern for WellItem result attachment (#1166)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a bug where invalid/unknown locales would default to month-first (American) format instead of day-first format. Since most of the world uses day-first, this is the better default.
Problem
When an invalid or unknown locale was provided (e.g., typo, unsupported locale), the exception handler would return
False(month-first):This caused incorrect parsing:
locale="xyz_ABC"(typo)"01/02/2023"gets parsed as January 2nd (month-first)Why this is wrong
Only a handful of locales use month-first format:
en_US- American EnglishMost of the world uses day-first:
Solution
Changed exception handler to return
True(day-first) for invalid locales:The logic now:
YYYY-MM-DD) →False(month before day)None) →False(backward compat, American default)True(day-first is global default)Code Changes
Before:
After:
Testing
Updated test:
New integration test:
Impact
Nonelocale still defaults to American format🤖 Generated with Claude Code